crash捕获介绍
文章转载至 https://www.jianshu.com/p/d2b7a2eb36ba
##
如果对crash捕获不太了解,可以先参考这篇文章,本文进行
Mach异常+Unix信号方式
捕获crash。NSException一般只在OC当中被捕获,一般情况下在捕获NSException异常后同时也会捕获到一个对应的signal异常。但如果你使用的是纯swift开发,如下代码并不会捕获相关的crash
1
NSSetUncaughtExceptionHandler(UncaughtExceptionHandler)
swift崩溃捕获
swift通常都是通过对应的signal来捕获crash。对于swift的崩溃捕获,Apple的文档中有描述说需要通过
SIGTRAP
信号捕获强转失败,及非可选的nil值导致的崩溃.具体描述如下:1
2
3
4
5
6
7Trace Trap[EXC_BREAKPOINT // SIGTRAP]
类似于异常退出,此异常旨在使附加的调试器有机会在其执行中的特定点中断进程。您可以使用该__builtin_trap()函数从您自己的代码触发此异常。如果没有附加调试器,则该过程将终止并生成崩溃报告。
较低级的库(例如,libdispatch)会在遇到致命错误时捕获进程。有关错误的其他信息可以在崩溃报告的“ 附加诊断信息”部分或设备的控制台中找到。
如果在运行时遇到意外情况,Swift代码将以此异常类型终止,例如:
1.具有nil值的非可选类型
2.一个失败的强制类型转换对于swift还有一种崩溃需要捕获(Intel处理器,我认为应该是指在模拟器上的崩溃),为保险起见,也需要将信号
SIGILL
进行注册,Apple同样对其中做了描述1
2
3Illegal Instruction[EXC_BAD_INSTRUCTION // SIGILL]
该过程尝试执行非法或未定义的指令。该过程可能尝试通过错误配置的函数指针跳转到无效地址。
在Intel处理器上,ud2操作码引起EXC_BAD_INSTRUCTION异常,但通常用于进程调试目的。如果在运行时遇到意外情况,Intel处理器上的Swift代码将以此异常类型终止。有关详细信息,请参阅Trace Trap。
crash捕获实现代码参考
1 | //对于OC的exception采取如下方式捕获 |
获取Slide Address
通过获取到偏移量地址Slide Address
和错误信息的内存地址
基本即可定位错误,错误信息的内存地址在捕获的crash信息中会体现,Slide Address
则需要我们自己获取,通过调用如下C方法我们可以获取到偏移量地址,这里通过OC文件来调用C方法。方法如下:
1 | //MARK: - 获取偏移量地址 |
crash分析介绍
- 如果想要定位错误,通过拿到
Slide Address
和错误信息的内存地址
即可定位(实际上错误信息地址可以通过Slide Address加上偏移量获得) - 拿到
Slide Address
和错误信息的内存地址
后我们可以通过一个开源工具dSYMTools直接定位到我们想要的信息。感谢作者的贡献,让我们更加方便快捷的分析问题。 - dSYMTools 需要传入.xcarchive文件,你可以通过Xcode找到你对应提交版本的.xcarchive。你也可以在提交前保留对应的.xcarchive,以供万一产生crash分析使用,这里的.xcarchive一定要与产生crash信息的版本对应,否则无法定位到崩溃信息
具体分析
当自己捕获NSException Crash并上传到服务器之后,正常crash大概会显示信息如下,我们大概能够知道是由于数组溢出导致的崩溃。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26Stack:
slideAdress:0xec000
name:NSRangeException
reason:Optional("*** -[__NSArray0 objectAtIndex:]: index 66 beyond bounds for empty NSArray")
0 CoreFoundation 0x0000000181646ff0 <redacted> + 148
1 libobjc.A.dylib 0x00000001800a8538 objc_exception_throw + 56
2 CoreFoundation 0x00000001815b2eb8 <redacted> + 0
3 CrashManager 0x00000001000f3000 CrashManager + 28672
4 UIKit 0x00000001877ab0ec <redacted> + 96
5 UIKit 0x00000001877ab06c <redacted> + 80
6 UIKit 0x00000001877955e0 <redacted> + 440
7 UIKit 0x00000001877aa950 <redacted> + 576
8 UIKit 0x00000001877aa46c <redacted> + 2480
9 UIKit 0x00000001877a5804 <redacted> + 3192
10 UIKit 0x0000000187776418 <redacted> + 340
11 UIKit 0x0000000187f6ff64 <redacted> + 2400
12 UIKit 0x0000000187f6a6c0 <redacted> + 4268
13 UIKit 0x0000000187f6aaec <redacted> + 148
14 CoreFoundation 0x00000001815f5424 <redacted> + 24
15 CoreFoundation 0x00000001815f4d94 <redacted> + 540
16 CoreFoundation 0x00000001815f29a0 <redacted> + 744
17 CoreFoundation 0x0000000181522d94 CFRunLoopRunSpecific + 424
18 GraphicsServices 0x0000000182f8c074 GSEventRunModal + 100
19 UIKit 0x00000001877db130 UIApplicationMain + 208
20 CrashManager 0x00000001000f139c CrashManager + 21404
21 libdyld.dylib 0x000000018053159c <redacted> + 4如上所示,slideAdress我们已经通过程序获取,这里是0xec000,由上往下找,我们可以看到
3 CrashManager 0x00000001000f3000 CrashManager + 28672
出现了CrashManager信息,那么0x00000001000f3000则有可能为我们想要定位的错误信息地址。将我们得到数据带入工具可清晰定位到错误:
NSException错误信息.png
如果捕获到的Signal Crash,可能crash显示的信息大概会如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25Stack:
slideAdress:0xa4000
0 CrashManager 0x00000001000a8f10 CrashManager + 20240
1 CrashManager 0x00000001000a9024 CrashManager + 20516
2 libsystem_platform.dylib 0x000000018070530c _sigtramp + 36
3 CrashManager 0x00000001000ab1bc CrashManager + 29116
4 CrashManager 0x00000001000aaa64 CrashManager + 27236
5 UIKit 0x00000001877ab0ec <redacted> + 96
6 UIKit 0x00000001877ab06c <redacted> + 80
7 UIKit 0x00000001877955e0 <redacted> + 440
8 UIKit 0x00000001877aa950 <redacted> + 576
9 UIKit 0x00000001877aa46c <redacted> + 2480
10 UIKit 0x00000001877a5804 <redacted> + 3192
11 UIKit 0x0000000187776418 <redacted> + 340
12 UIKit 0x0000000187f6ff64 <redacted> + 2400
13 UIKit 0x0000000187f6a6c0 <redacted> + 4268
14 UIKit 0x0000000187f6aaec <redacted> + 148
15 CoreFoundation 0x00000001815f5424 <redacted> + 24
16 CoreFoundation 0x00000001815f4d94 <redacted> + 540
17 CoreFoundation 0x00000001815f29a0 <redacted> + 744
18 CoreFoundation 0x0000000181522d94 CFRunLoopRunSpecific + 424
19 GraphicsServices 0x0000000182f8c074 GSEventRunModal + 100
20 UIKit 0x00000001877db130 UIApplicationMain + 208
21 CrashManager 0x00000001000a939c CrashManager + 21404
22 libdyld.dylib 0x000000018053159c <redacted> +
一般我们无法从signal产生的这些信息中直观获取到crash产生的原因,这里崩溃的地址我们一般优先选择_sigtramp后第一条有我们程序信息的地址,所以这里将slideAdress:0xa4000和可能的错误信息地址0x00000001000ab1bc代入:
signalCrash.png
注意事项
- 如果你使用工具解析后得到的信息是类似于这样的
_hidden#30_ (in libswiftObjectiveC.dylib) (__hidden#70_:0)
,那么极有可能是因为你提交版本的时候勾选了BitCode,勾选了Bitcode之后,用户安装的二进制文件是苹果服务器经过优化后生成的,其对应的调试符号信息丢失了,所以你看到的全部是类似于__hidden#70_:0
这样的信息,所以也无法通过还原奔溃现场找原因了.如果你如果你不太理解BitCode,可以参考这篇BitCode介绍和这篇讨论 - 如果你使用模拟器,那么由于本身绑定相关dSYM文件,你获取到的crash信息中可能不是错误地址而是很明显的相关错误信息,这不在本文讨论范围内,毕竟在调试过程中获取崩溃信息相对容易,本文阐述的是你的应用已经提交后捕获和分析用户使用过程中产生的crash
资源支持
这是一个完整的Demo,本篇文章所阐述的内容在Demo中都有体现,你可以直接使用Demo中的模块完成Crash捕获,也可以参考Demo阅读本文,相信可以更快理解,如果对你有帮助,给个star呗。
crash捕获参考文档连接
-